Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-mimemhs-body-equival-02.txt < prev next >

Wrap

Text File | 1993-03-03 | 35.9 KB | 1,378 lines

draft X.400/MIME body equivalences Jun 92 Equivalences between 1988 X.400 and RFC-822 Message Bodies Thu Jun 25 19:50:44 1992 Harald Tveit Alvestrand SINTEF DELAB Harald.T.Alvestrand@delab.sintef.no Steven J. Thompson Soft*Switch, Inc. sjt@gateway.ssw.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. If consensus is reached in the IETF MIME-MHS Interworking Working Group, it will be submitted to the IESG asking that it be recommended to the IAB as a Proposed Standard protocol specification. Please send comments to the MIME-MHS mailing list: <mime-mhs@surfnet.nl> Alvestrand, Thompson Exp Dec 92 [Page 1] draft X.400/MIME body equivalences Jun 92 1. Introduction This document is a companion to [MAPPING], which defines the principles behind interworking between MIME-based RFC-822 mail and X.400 mail. This document describes the content of the "IANA MHS/MIME Equivalence table" referenced in the companion document, and defines the initial configuration of this table. Mappings for new MIME content-types and/or X.400 body part types should be registered with the IANA to minimize redundancy and promote interoperability. In MIME, the term "content-type" is used to refer to an information object contained in the body of a message. In contrast, X.400 uses the term "body part type." In this document, the term "body part" is used to refer to either. Alvestrand, Thompson Exp Dec 92 [Page 2] draft X.400/MIME body equivalences Jun 92 2. Equivalence Table Definition For each MIME content-type/X.400 body part pair, the Equivalence Table will contain an entry with the following sections: X.400 Body Part This section identifies the X.400 Body Part governed by this Table entry. It includes any OBJECT IDENTIFIERs or other parameters necessary to uniquely identify the Body Part. MIME Content-Type This section identifies the MIME content-type governed by this Table entry. The MIME content-type named here must be registered with the IANA. Conversion Type This section identifies the type of conversion applied. See the section on Generic Conversions for an explanation of the possible values. Comments (optional) This section gives any additional commentary that might be useful in understanding the mapping between the X.400 and MIME representations. The initial Equivalence Table entries in this document are described using this convention. Any future submissions to the IANA should follow this format. Alvestrand, Thompson Exp Dec 92 [Page 3] draft X.400/MIME body equivalences Jun 92 3. Generic conversions 3.1. Byte copy This is the trivial case, that is, no conversion at all. The byte stream is simply copied between MIME and X.400. This is the preferred conversion, since it is the simplest. Implementors and vendors will be registering OBJECT IDENTIFIERs and MIME content-types for their various objects. They are STRONGLY ENCOURAGED to specify their content formats such that a gateway can use Byte Copy to map between them. Note that in some cases, it is necessary to define exactly which ASN.1 construct to replace with the content of the MIME object. 3.2. Text Conversion This type of conversion applies to text objects that cannot be mapped using a simple Byte Copy. Conversion involves scanning and reformatting the object. For example, the MIME and X.400 objects might differ in their encoding of nonstandard characters, or line or page breaks. 3.3. Image Conversion This conversion type applies to raster images, like Group 3 Facsimile or JPEG. Again, it differs from Byte Copy in that it involves scanning reformatting the byte stream. It differs from Text Conversion in that it is pixel- oriented, rather than character-oriented. 3.4. Tunneling This is not a conversion at all, but an encapsulation of the object. This is the fallback conversion, used when no explicit mapping applies. Alvestrand, Thompson Exp Dec 92 [Page 4] draft X.400/MIME body equivalences Jun 92 4. Conversion Table for known X.400 and MIME Types This section itemizes the equivalences for all currently known MIME content-types and X.400 body parts. 4.1. MIME to X.400 Table MIME content-type X.400 Body Part Section ----------------- ------------------ ------- text/plain charset=us-ascii ia5-text 7.1 charset=iso-8859-x EBP - GeneralText 7.2 text/richtext no mapping defined 5.2 application/oda EBP - ODA 7.4 application/octet-stream bilaterally-defined 7.3 application/postscript EBP - mime-postscript-body 5.4, 7.6 image/g3fax g3-facsimile 6.2, 7.5 image/jpeg EBP - mime-jpeg-body 5.5, 7.7 image/gif EBP - mime-gif-body 5.6, 7.8 audio/basic no mapping defined 5.2 video/mpeg no mapping defined 5.2 Abbreviation: EBP - Extended Body Part 4.2. X.400 to MIME Table Basic Body Parts X.400 Basic Body Part MIME content-type Section --------------------- -------------------- ------- ia5-text text/plain;charset=us-ascii 7.1 voice No Mapping Defined 6.1 g3-facsimile image/g3fax 6.2, 7.5 g4-class1 no mapping defined 6.1 teletex no mapping defined 6.1 videotex no mapping defined 6.1 encrypted no mapping defined 6.1 bilaterally-defined application/octet-stream 7.3 nationally-defined no mapping defined 6.1 externally-defined See Extended Body Parts 6.1 X.400 Extended Body Part MIME content-type Section ------------------------- -------------------- ------- GeneralText text/plain;charset=iso-8859-x 7.2 Alvestrand, Thompson Exp Dec 92 [Page 5] draft X.400/MIME body equivalences Jun 92 ODA application/oda 7.4 mime-postscript-body application/postscript 5.3, 7.6 mime-jpeg-body image/jpeg 5.4, 7.7 mime-gif-body image/gif 5.5, 7.8 Alvestrand, Thompson Exp Dec 92 [Page 6] draft X.400/MIME body equivalences Jun 92 5. Newly defined X.400 Body Parts This section defines new X.400 Body Parts for the purposes of interworking with MIME. All new X.400 Body Parts defined here will be Extended Body Parts, as defined in CCITT Recommendation X.420 [X.420]. 5.1. Use of OBJECT IDENTIFIERs and ASN.1 MACROS X.420 dictates that Extended Body Parts shall: (1) use OBJECT IDENTIFIERs (OIDs) to uniquely identify the contents, and (2) be defined by using the ASN.1 Macro: EXTENDED-BODY-PART-TYPE MACRO::= BEGIN TYPE NOTATION ::= Parameters Data VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) Parameters ::= "PARAMETERS" type "IDENTIFIED" "BY" value(OBJECT IDENTIFIER) | empty; Data ::= "DATA" type END To meet these requirements, this document uses the OID mime-mhs-bodies defined in [MAPPING], as the root OID for X.400 Extended Body Parts defined for MIME interworking. Each Extended Body Part contains Data and optional Parameters, each being named by an OID. To this end, two OID subtrees are defined under mime-mhs-bodies, one for Data, and the other for Parameters: mime-mhs-bp-data OBJECT IDENTIFIER ::= { mime-mhs-bodies 1 } Alvestrand, Thompson Exp Dec 92 [Page 7] draft X.400/MIME body equivalences Jun 92 mime-mhs-bp-parameter OBJECT IDENTIFIER ::= { mime-mhs-bodies 2 } All definitions of X.400 body parts submitted to the IANA for registration must use the Extended Body Part Type macro for the definition. See the next section for an example. Lastly, the IANA will use the mime-mhs-bp-data and mime- mhs-bp-parameter OIDs as root OIDs for any new MIME content-type/subtypes that aren't otherwise registered in the Equivalence Table. 5.2. The Generic MIME Extended Body Part The following X.400 Body Part is defined to carry any MIME content-type for which there is no explicit IANA registered mapping. mime-body-part EXTENDED-BODY-PART-TYPE PARAMETERS MimeParameters IDENTIFIED BY mime-generic-parameters DATA OCTET STRING ::= mime-generic-data MimeParameters ::= SEQUENCE { content-type IA5String, content-parameters SEQUENCE OF SEQUENCE { parameter IA5String, parameter-value IA5String } -- from RFC-1327, sec. 5.1.12 other-header-fields RFC822FieldList } mime-generic-parameters OBJECT IDENTIFIER ::= { mime-mhs-bp-parameter 1 } mime-generic-data OBJECT IDENTIFIER ::= { mime-mhs-bp-data 1 } Alvestrand, Thompson Exp Dec 92 [Page 8] draft X.400/MIME body equivalences Jun 92 To convert the MIME content-type into the X.400 mime- body-part: (1) Copy the "type/subtype" string from the MIME Content-Type: header field into MimeParameters.content-type (2) For each "parameter=value" string in the MIME Content-Type header field, create a MimeParameters.content-parameters structure, and copy the "parameter" string into MimeParameters.content- parameters.parameter field and the "value" string into the paired MimeParameters.content- parameters.parameter-value field. (3) Convert the MIME body part into its canonical form. (See appendix H of RFC 1341 [MIME] for a discussion of canonical in this context.) Said another way, reverse the transfer encoding to recover the original byte stream. (4) Copy the canonical byte stream into the mime-body- part.data octet string. (5) Remove the Content-type and the Content-transfer- encoding header fields from the MIME body part's RFC822 header. (6) Any header fields starting with "Content-" in the MIME body part is placed in the optional other- header-fields structure. Note that this can only occur when the MIME content-type occurs as part of a "multipart" content-type. The mapping from the X.400 mime-body-part to a MIME content-type is the inverse of the above steps. 5.3. The PostScript body part The following Extended Body Part is defined for PostScript data streams. It has no parameters. postscript-body-part EXTENDED-BODY-PART-TYPE Alvestrand, Thompson Exp Dec 92 [Page 9] draft X.400/MIME body equivalences Jun 92 DATA OCTET STRING ::= mime-postscript-body mime-postscript-body OBJECT IDENTIFIER ::= { mime-mhs-bp-data 2 } 5.4. The JPEG body part The following Extended Body Part is defined for JPEG data streams. It has no parameters. jpeg-body-part EXTENDED-BODY-PART-TYPE DATA OCTET STRING ::= mime-jpeg-body mime-jpeg-body OBJECT IDENTIFIER ::= { mime-mhs-bp-data 3 } 5.5. The GIF body part The following Extended Body Part is defined for GIF data streams. It has no parameters. gif-body-part EXTENDED-BODY-PART-TYPE DATA OCTET STRING ::= mime-gif-body mime-gif-body OBJECT IDENTIFIER ::= { mime-mhs-bp-data 4 } Alvestrand, Thompson Exp Dec 92 [Page 10] draft X.400/MIME body equivalences Jun 92 6. Newly defined MIME content-types This section defines new MIME content-types for the purposes of interworking with X.400. 6.1. The application/x400-bp content-type This content-type is defined to carry any X.400(88) body part for which there is no registered IANA mapping. The content-type field is application/x400-bp The parameters are: bp-type=<INTEGER or OBJECT IDENTIFIER> The body contains the raw ASN.1 IPM.body octet stream, including the initial tag octet. If the body is a basic body part, the bp-type parameter is set to the number of the body part's context-specific tag, that is, the tag of the IPMS.Body.BodyPart component. If the body is an Extended Body Part, the bp-type parameter is set to the OBJECT IDENTIFIER from IPMS.body.externally-defined.data.direct-reference No attempt is made to turn the parameters of Extended Body Parts into MIME parameters. (This task is the responsibility of the recipient's UA). For example, a basic VideotexBodyPart will have Content-type=application/x400-bp; bp-type=6 whilst a Extended Videotex body part will have Content-type=application/x400-bp; bp-type=2.6.1.4.5 Alvestrand, Thompson Exp Dec 92 [Page 11] draft X.400/MIME body equivalences Jun 92 6.2. The image/g3fax content-type This content-type is defined to carry G3 Facsimile byte streams. In general, a G3Fax image contains 3 pieces of information: (1) A set of flags indicating the particular coding scheme. CCITT Recommendation T.30 defines how the flags are transmitted over telephones. In this medium, the flags are carried as parameters in the MIME content-type header field. (2) A structure that divides the bits into pages. CCITT recommendation T.30 describes how to define page boundaries. A page break algorithm is defined here that is independent of how the image data is conveyed. (3) For each page, a sequence of bits that form the encoding of the image. CCITT recommendation T.4 defines the bit image format. This is used without change. 6.2.1. G3Fax Parameters The following parameters are defined: (1) page-length - possible values: A4, B4 and Unlimited (2) page-width - possible values: A3, A4, B4 (3) encoding - possible values: 1-dimensional, 2- dimensional, Uncompressed (4) resolution - possible values: Fine, Coarse (5) DCS - a bit string, represented in Base64. (6) pages - an integer, giving the number of pages in the document Alvestrand, Thompson Exp Dec 92 [Page 12] draft X.400/MIME body equivalences Jun 92 If nothing is specified, the default parameter settings are: page-length=A4 page-width=A4 encoding=1-dimensional resolution=Coarse It is possible (but misleading) to view the representation of these values as single-bit flags. They correspond to the following bits of the T.30 control string and X.400 G3FacsimileParameters: Parameter T.30 bit X.400 bit page-length=A4 no bit set page-length=B4 19 21 page-length=Unlimited 20 20 page-width=A4 no bit set page-width=A3 18 22 page-width=B4 17 23 encoding=1-dimensional no bit set encoding=2-dimensional 16 8 encoding=Uncompressed 26 30 resolution=Coarse no bit set resolution=Fine 15 9 The reason for the different bit numbers is that X.400 counts bits in an octet from the MSB down to the LSB, while T.30 uses the opposite numbering scheme. If any bit but these are set in the Device Control String, the DCS parameter should be supplied. 6.2.2. Content Encoding X.400 defines the g3-facsimile data stream as a SEQUENCE of BIT STRINGs. Each BIT STRING is a page of facsimile image data, encoded as defined by Recommendation T.4. The following content encoding is reversible between MIME and X.400 and ensures that page breaks are honored in the MIME Alvestrand, Thompson Exp Dec 92 [Page 13] draft X.400/MIME body equivalences Jun 92 representation. An EOL is defined as a bit sequence of 000000000001 (eleven zeroes and a one). Each page of the message is delimited by a sequence of six (6) EOLs that MUST start on a byte boundary. The image bit stream is padded as needed to achieve this alignment. Searching for the boundary is a matter of searching for the byte sequence (HEX) 00 10 01 00 10 01 00 10 01, which cannot occur inside the image. See Section 7.5 for the algorithm on conversion between this encoding and the X.400 encoding. 7. Equivalence Definitions 7.1. IA5Text - text/plain X.400 Body Part: IA5Text MIME Content-type: text/plain; charset=US-ASCII Conversion Type: Byte copy Comments: When mapping from X.400 to MIME, the "repertoire" parameter is ignored. When mapping from MIME to X.400, the "repertoire" parameter is set to IA5 (5). NOTE: The MIME Content-type headers are omitted, when mapping from X.400 to MIME, if and only if the IA5Text body part is the only body part in the IPMS.Body sequence. NOTE: IA5Text specifies the "currency" symbol in position 2/4. This is converted without comment to the "dollar" symbol, since the author of this document has seen many documents in which the position was intended to indicate "dollar" while he has not yet seen one in which the "currency" symbol is intended. Alvestrand, Thompson Exp Dec 92 [Page 14] draft X.400/MIME body equivalences Jun 92 (For reference: The T.50 (1988) recommendation, which defines IA5, talks about ISO registered set number 2, while ASCII, using the "dollar" symbol, is ISO registered set number 6. There are no other differences.) 7.2. GeneralText - text/plain (ISO-8859) X.400 Body Part: GeneralText; CharacterSets in 6,100,101,109,110,126,127,138,144,148 MIME Content-Type: text/plain; charset=ISO-8859-(1-9) Conversion Type: Byte copy Comments: When mapping from X.400 to MIME, the character-set chosen from table below according to the value of Parameters.CharacterSets. When mapping from MIME to X.400, GeneralText is an Extended Body Part, hence it requires an OID. The OID for the GeneralText body is defined in [MOTIS], part 8, annex D, as {2 6 1 4 11}. The OID for the parameters is {2 6 1 11 11}. The Parameters.CharacterSets is set from table below according to the value of "charset" NOTE: The GeneralText body part is defined in ISO 10021-8 [MOTIS], and NOT in the corresponding CCITT recommendation. Its parameters were heavily modified in a defect report, and will be a SET OF INTEGER (indicating the ISO registry numbers of all the used sets) in the next version of the standard. The following table lists the MIME character sets and the corresponding ISO registry numbers. If no correspondence is found, this conversion fails, and the generic body part approach is used. MIME charset ISO IR numbers Comment ----------------------------------------------- ISO-8859-1 6, 100 West European "8-bit ASCII" ISO-8859-2 6, 101 East European ISO-8859-3 6, 109 <regarded as obsolete> ISO-8859-4 6, 110 <regarded as obsolete> Alvestrand, Thompson Exp Dec 92 [Page 15] draft X.400/MIME body equivalences Jun 92 ISO-8859-5 6, 144 Cyrillic ISO-8859-6 6, 127 Arabic ISO-8859-7 6, 126 Greek ISO-8859-8 6, 138 Hebrew ISO-8859-8 6, 148 Other Latin-using languages When converting from MIME to X.400, generate the correct OIDs for use in the message envelope's Encoded Information Types by looking up the ISO IR number in the above table, and then appending it to the id-cs-eit-authority {1 0 10021 7 1 0} OID. The escape sequences to designate and invoke the relevant character sets in their proper positions must be added to the front of the GeneralText character string. 7.3. BilaterallyDefined - application/octet-stream X.400 Body Part: BilaterallyDefined MIME Content-Type: Application/Octet-Stream (no parameters) Conversion Type: Byte copy Comments: When mapping from MIME to X.400, if there are parameters present in the Content-Type: header field, the conversion fails since the BilaterallyDefined Body Part does not have any corresponding ASN.1 parameters. DISCUSSION: The parameters "name" "type" and "conversions" are advisory, but may in some cases give vital hints on the expected handling of the file. The parameter "conversions" is not fully defined, but it is expected that it will be useful, so we cannot drop it and expect people to be satisfied. The parameter "padding" changes the interpretation of the last byte of the data, and so cannot be deleted. An option is to prepend an IA5 body part that contains the parameter text; this will aid unmodified readers, and can probably be made reversible with suitable chicanery, but is it worth it???? Alvestrand, Thompson Exp Dec 92 [Page 16] draft X.400/MIME body equivalences Jun 92 Also, use of BilaterallyDefined Body Parts is specifically deprecated in both 1988 and 1992 X.400. It is retained solely for backward compatibility with 1984 systems. 1992 X.400 defines a File Transfer Body Part to solve this problem (i.e. binary file transfer through email). The standard and its regional profiles are not solid enough yet to exploit as a solution for this problem. 7.4. ODA - application/oda X.400 Body Part: ODA MIME Content-Type: application/oda Conversion Type: Byte copy Comments: The ODA body part is defined in the CCITT document T.411 [T.411], appendix E, section E.2, "ODA identification in the P2 protocol of MHS" An abbreviated version of its ASN.1 definition is: oda-body-part EXTENDED-BODY-PART-TYPE PARAMETERS OdaBodyPartParameters DATA OdaData ::= id-et-oda OdaBodyPartParameters ::= SET { document-application-profile [0] OBJECT IDENTIFIER document-architecture-class [1] INTEGER { formatted (0) processable (1) formatted-processable(2)}} id-et-oda OBJECT IDENTIFIER ::= { 2 8 1 0 1 } Mapping from X.400 to MIME, the following is done: The Parameters.document-application-profile is mapped onto the MIME parameter "profile" according to the table below. Profile OBJECT IDENTIFIER Q112 { iso (1) identified-organization (3) ewos (16) Alvestrand, Thompson Exp Dec 92 [Page 17] draft X.400/MIME body equivalences Jun 92 eg (2) oda (6) profile (0) q112 (1) } The Parameters.document-architecture-class is mapped onto the MIME parameter "class" according to the table below String Integer formatted formatted(0) processable processable(1) formatted-processable formatted-processable(2) NOTE: This parameter is not defined in the MIME document. The body of the MIME content-type is the Data part of the ODA body part. When mapping from MIME to X.400, the following steps are done: The Parameters.document-application-profile and Parameters.document-architecture-class are set from the tables above. If any of the parameters are missing, the values for Q112 and formatted-processable are used. It is an option for the gateway implementor to try to access them from inside the document, where they are defined as document-profile.document-characteristics.document-architecture-class document-profile.document-characteristics.document-application-profile Gateways are NOT required to do this, since the document- characteristics are optional parameters. If a gateway does not, it simply uses the defaulting rules defined above. The OBJECT IDENTIFIERs for the document application profile and for ODA {2 8 0 0} must be added to the Encoded Information Types parameter of the message envelope. Alvestrand, Thompson Exp Dec 92 [Page 18] draft X.400/MIME body equivalences Jun 92 7.5. g3-facsimile - image/g3fax X.400 Body part: g3-facsimile MIME Content-Type: image/g3fax Conversion Type: nearly Byte copy Comments: The Parameters of the X.400 G3Fax body part are mapped to the corresponding Parameters on the MIME Image/G3Fax body part and vice versa. Note that: (1) If fineResolution is not specified, pixels will be twice as tall as they are wide (2) If any bit not corresponding to a specially named option is set in the G3Fax NonBasicParameters, the "DCS" parameter must be used. (3) Interworking is not guaranteed if any bit apart from those specially named are used in the NonBasicParameters From X.400 to G3Fax, the body is created in the following way: (1) Any trailing EOL markers on each bitstring is removed. The bistring is padded to a byte boundary. (2) 6 consecutive EOL markers are appended to each bitstring. (3) The padded bitstrings are concatenated together An EOL marker is the bit sequence 000000000001 (11 zeroes and a one). From G3Fax to X.400, the body is created in the following way: (1) The body is split into bitstrings at each occurrence of 6 consecutive EOL markers, and trailing EOLs and padding are removed (2) Each bitstring is made into an ASN.1 BITSTRING Alvestrand, Thompson Exp Dec 92 [Page 19] draft X.400/MIME body equivalences Jun 92 (3) The bitstrings are made into an ASN.1 SEQUENCE, which forms the body of the G3Fax body part. 7.6. application/postscript - postscript-body-part X.400 Body Part: Extended Body Part, OID postscript-body-part MIME Content-Type: application/postscript Conversion Type: Byte Copy 7.7. application/jpeg - jpeg-body-part X.400 Body Part: Extended Body Part, OID jpeg-body-part MIME Content-Type: application/jpeg Conversion Type: Byte Copy 7.8. image/gif - gif-body-part X.400 Body Part: Extended Body Part, OID gif-body-part MIME Content-Type: application/gif Conversion Type: Byte Copy Alvestrand, Thompson Exp Dec 92 [Page 20] draft X.400/MIME body equivalences Jun 92 8. OID Assignments MIME-MHS-MAPPINGS DEFINITIONS ::= BEGIN EXPORT -- everything --; IMPORTS experimental FROM RFC1155-SMI; mime-mhs FROM MIME-MHS --Companion RFC--; mime-mhs-bp-data OBJECT IDENTIFIER ::= { mime-mhs-bodies 1}; mime-mhs-bp-parameter OBJECT IDENTIFIER ::= { mime-mhs-bodies 2}; mime-generic-data OBJECT IDENTIFIER ::= { mime-mhs-bp-data 1}; mime-generic-parameters OBJECT IDENTIFIER ::= { mime-mhs-bp-parameter 1}; mime-postscript-body OBJECT IDENTIFIER ::= { mime-mhs-bp-data 2}; mime-jpeg-body OBJECT IDENTIFIER ::= { mime-mhs-bp-data 3}; mime-gif-body OBJECT IDENTIFIER ::= { mime-mhs-bp-data 4}; Alvestrand, Thompson Exp Dec 92 [Page 21] draft X.400/MIME body equivalences Jun 92 9. IANA Registration form for new mappings To: IANA@isi.edu Subject: Registration of new X.400/MIME content type mapping MIME type name: (this must have been registered previously with IANA) X.400 body part: X.400 Object Identifier for Data: (If left empty, an OID will be assigned by IANA under mime-mhs-bp-data) X.400 Object Identifier for Parameters: (If left empty, an OID will be assigned by IANA under mime-mhs-bp-parameter. If it is not used, fill in the words NOT USED.) X.400 ASN.1 Syntax: (must be an EXTENDED-BODY-PART-TYPE macro, or reference to a Basic body part type) Conversion algorithm: (must be defined completely enough for independent implementation. It may be defined by reference to RFCs). Person & email address to contact for further information: INFORMATION TO THE SUBMITTER: The accepted registrations will be listed in the "Assigned Numbers" series of RFCs. The information in the registration form is freely distributable. 10. References [RFC-822] D.H. Crocker, Standard for the Format of ARPA Alvestrand, Thompson Exp Dec 92 [Page 22] draft X.400/MIME body equivalences Jun 92 Internet Text Messages. Request for Comments 822, (August, 1982). [MIME] N. Borenstein, N. Freed, MIME: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. Request for Comments 1341, (June, 1992). [RFC-1327] S.E. Hardcastle-Kille, Mapping between X.400(1988) / ISO 10021 and RFC-822. [MAPPING] H.T. Alvestrand, R.S. Miles, M.T. Rose, S.J. Thompson, Mapping between X.400 and RFC-822 Message Bodies Internet-Draft, (June , 1992). [T.4] CCITT Recommendation T.4, Standardization of Group 3 Facsimile Apparatus for Document Transmission (1988) [T.30] CCITT Recommendation T.30, Procedures For Document Facsimile Transmission in the General Switched Telephone Network (1988) [T.411] CCITT Recommendation T.411 (1988), Open Document Architecture (ODA) and Interchange Format, Introduction and General Principles [MOTIS] ISO/IEC International Standard 10021, Information technology - Text Communication - Message-Oriented Text Interchange Systems (MOTIS) (Parts 1 to 8) [X.400] CCITT, Data Communication Networks - Message Handling Systems - Recommendations X.400 - X.420 (1988 version) [X.420] CCITT Recommendation X.420 (1988), Interpersonal Messaging System Alvestrand, Thompson Exp Dec 92 [Page 23] draft X.400/MIME body equivalences Jun 92 [RFC-X400USE] Harald Tveit Alvestrand, X.400 use of extended Character Sets, Internet Draft, June 1992 Alvestrand, Thompson Exp Dec 92 [Page 24] draft X.400/MIME body equivalences Jun 92 Table of Contents Status of this Memo ................................ 1 1 Introduction ...................................... 2 2 Equivalence Table Definition ...................... 3 3 Generic conversions ............................... 4 3.1 Byte copy ....................................... 4 3.2 Text Conversion ................................. 4 3.3 Image Conversion ................................ 4 3.4 Tunneling ....................................... 4 4 Conversion Table for known X.400 and MIME Types ................................................ 5 4.1 MIME to X.400 Table ............................. 5 4.2 X.400 to MIME Table ............................. 5 5 Newly defined X.400 Body Parts .................... 7 5.1 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ...... 7 5.2 The Generic MIME Extended Body Part ............. 8 5.3 The PostScript body part ........................ 9 5.4 The JPEG body part .............................. 10 5.5 The GIF body part ............................... 10 6 Newly defined MIME content-types .................. 11 6.1 The application/x400-bp content-type ............ 11 6.2 The image/g3fax content-type .................... 12 6.2.1 G3Fax Parameters .............................. 12 6.2.2 Content Encoding .............................. 13 7 Equivalence Definitions ........................... 14 7.1 IA5Text - text/plain ............................ 14 7.2 GeneralText - text/plain (ISO-8859) ............. 15 7.3 BilaterallyDefined - application/octet-stream ................................................ 16 7.4 ODA - application/oda ........................... 17 7.5 g3-facsimile - image/g3fax ...................... 19 7.6 application/postscript - postscript-body-part ................................................ 20 7.7 application/jpeg - jpeg-body-part ............... 20 7.8 image/gif - gif-body-part ....................... 20 8 OID Assignments ................................... 21 9 IANA Registration form for new mappings ........... 22 10 References ....................................... 22 Alvestrand, Thompson Exp Dec 92 [Page 25]